home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19950329-19950528 / 000383_news@columbia.edu_Mon May 15 13:19:07 1995.msg < prev    next >
Internet Message Format  |  1995-07-31  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA14257
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 15 May 1995 09:19:20 -0400
  3. Received: by apakabar.cc.columbia.edu id AA12517
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 15 May 1995 09:19:18 -0400
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Maxium size for string to output?
  9. Date: 15 May 1995 13:19:07 GMT
  10. Organization: Columbia University
  11. Lines: 26
  12. Message-Id: <3p7kcb$c6u@apakabar.cc.columbia.edu>
  13. References: <3oroce$opq@news0.cybernetics.net>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3oroce$opq@news0.cybernetics.net>,
  18. Milton A. Baucom <mbaucom@cybernetics.net> wrote:
  19. >I've seem to run across an interesting thing in CKermit 190 for XENIX.  If
  20. >I try to output a string that is 320 characters long, the receiving system
  21. >acts as if a partial string was sent.  It also appears as if there are some
  22. >control characters being sent.  (There are none in the string.)  If I split
  23. >the line into 79 character chunks, all is well.
  24. >
  25. >Is there some sort of buffer being used for the output command?
  26. >
  27. Well, yes.  And it is 80 indeed bytes long.  However, unless I'm badly
  28. mistaken, the buffering algorithm (see dooutput() and oboc() in ckuus5.c)
  29. is sound.  It was tested successfully with strings considerably longer
  30. than 80 bytes (and longer than 320).
  31.  
  32. Failures like the one you report have been observed for various lengths,
  33. most commonly 256.  Generally, this indicates a flow-control or buffering
  34. capacity problem at the receiving end, and not a failure of the OUTPUT
  35. command.  It could also, however, be indicative of a buffering capacity
  36. in the local device drivers.
  37.  
  38. A good way to locate the culprit would be to test the OUTPUT command for
  39. success or failure.  If it succeeds, the problem is most likely on the
  40. far end.  If it fails, that means it was not able to send all the bytes.
  41.  
  42. - Frank